Part
of scaling out your farms is to know which services belong to which
tier. When you have gained this understanding, you can combine that
knowledge with demand estimates that you produce as part of your
capacity planning activities. This information will help you know which
servers you will need in your farm and which services will reside on
which servers. In Figure 1, these services are recommended for hosting on your Web servers.
Note:
Microsoft SharePoint Foundation User Code Service and Windows SharePoint Services Workflow Timer Service can also be deployed to application servers.
In larger environments,
many SharePoint 2010 services and service applications will be hosted in
the application tier on application servers dedicated to these
purposes. In smaller environments, you’ll find the Web front-end (WFE)
servers playing a dual role of hosting application tier services on the
same physical servers. Figure 2 illustrates the application tier services.
1. Planning Service Applications Architecture
The following list provides a
short review of some of the terminology that is used in the discussion
for scaling out service applications in SharePoint 2010 environments.
Service Actual program bits (binaries) deployed to servers in a farm to provide some type of functionality
Service machine instance Actual instance of the running service bits (binaries) running on an application server in the farm
Service application A specific configuration of the service in a farm
Service application proxy A reference point to the service application that exists on the WFE
Service Consumer A SharePoint 2010 feature that talks to the service application and provides the functionality to a user, such as a Web Part
Figure 7-13 illustrates a workflow process for
service application architecture. Viewing this image from the bottom to
the top, you move through a few layers to get to the services that an
end user might be trying to consume. You can see that an end user can
access a service consumer (a Web Part or a page). As you move upward,
you see that a service consumer then communicates with a service
application proxy. This proxy acts as the middle man and will continue
relaying the request or communication to the service application. The
service application then communicates with the service to perform the
operation. Depending on the configuration and scaling of the farm, you
could have multiple instances of Excel Services running on different
application servers. This is where the physical instances of those
services come in (service machine instances). There is redundancy within
this because SharePoint 2010 has a built-in load-balance mechanism that
will allow your requests to continue to be served even if an
application server with that particular service is unavailable. In Figure 3,
this redundancy is illustrated by the square around the four
application servers and the two databases at the top of the figure.
You now have the
ability to use the service applications individually as needed and to
scale them in ways that help maximize your farm. When you are designing
services architecture strategy for an organization, consider the ways in
which you can configure the individual services to enhance your overall
content sharing or isolation goals. Start thinking about grouping your services
based on business requirements and compliances. The business
requirements will change as the organization grows and you have to scale
out your servers or redesign your farm into multiple farms.
Note:
Planning for service application architecture is not necessary when you are using a limited deployment farm, but it is a good planning task to complete. Most limited deployment farms are proof of concept.
|
When you plan your service
application architecture, think about the following aspects of the
architecture prior to configuring your service applications.
Richness The ability to deliver more features and allowing third parties to build their own “shared services” Scalability The ability to handle larger loads, scale farms, and scale to the cloud Flexibility The ability to be more malleable in terms of granularity
Another point of
concern for administrators is performance. Understanding where your
servers are in relation to the end users who are consuming those
services is incredibly important. Services and the service applications
associated with them can be hindered by not providing for proper
performance. For instance, if you have the Search service on its own
application server and it is indexing a few million documents,
performance might be completely acceptable for users in the main office,
but what about remote users or users in another office that may be in
Europe or Asia? It is imperative that you understand how the
architecture will affect performance throughout your system. You can
also configure your service applications to either share resources
across multiple Web applications or provide content and resource
isolate. This granularity was something that was not possible in earlier
versions of SharePoint.
|
Note:
When planning your service
architecture, be aware that that some of the service applications create
their own databases when deployed, so additional SQL database planning
and maintenance will be required.
Figure 4
provides a visual representation of how you could group service
applications. Note that the default group is linked to multiple service
applications and to two Web applications from which those services are being consumed. These service applications could be, for
example, the Search service, the Metadata Manager service, or the
People service. These service applications are also cross-farm services,
so conceivably these Web applications could be sharing services coming
from a completely different farm.
Next, you can
isolate a service application. This isolation can be due to regulatory
or HIPPA compliances or some other internal business requirement.
Service application isolation levels can be applied to any of the
following.
Application pool
Web application
Application proxy group
Note:
If the service application
is a cross-farm service, you could also isolate it by making it a
separate farm. An example of this would be isolating the Search service
on its own farm.
Figure 5 provides an example of an isolated service
application. In this example, you can see that two Web applications are
sharing services coming from the default proxy group. You also can see a
third Web application that is isolated by itself, and you see the
service applications that it uses—Search and Business Data Connectivity.
You can imagine this as your human resources (HR) department using
Search and a payroll or benefits database that contains confidential
information. This information needs to be isolated and only consumed by
HR, because it contains personally identifiable information (PII).
2. Planning Topology Architecture
You can take the same
approach to scaling out these service applications in multiple farms as
you do for single farms. As user demand increases, you can scale up from
a small to medium farm by adding more WFEs and applications servers, as
well as additional service applications to the environment as needed.
Planning
topology architecture has a few physical considerations that you need
to address in order to plan how and what you will be scaling in your
environments—your scaling will influence your physical topology. You
should keep your host services
physically close to your users and content and also keep your services
close to your Active Directory to ensure better communication. Of
course, your budget constraints also can affect how you plan your
topology architecture.
In SharePoint 2010, when
scaling out services within the same environment, you can add additional
servers at each tier; when building out these application services, you
always want to group similar services together. For example, a server
can have just the search service on it or it might have only the
cross-farm services on it. Finally, you scale SQL for your datacentric
services or for business continuity requirements. As an example, you
might decide to move your search databases to a server by themselves.
Some factors that might
cause you to consider scaling out services include a company merger or
acquisition, or your organization might have new and increasing search
requirements. If you suddenly need to handle a much larger number of
searches or have much many more documents to search, then scaling out by
a couple of servers probably would not be able to handle the increase.
When you face a major challenge like this, you need to look at splitting
your services into another farm or multiple farms. You want to consider
security boundaries, your usage/scaling loads, any political or company
requirements, and you should also think about how you are going to
apply patches, hotfixes, and updates to this new environment.
Figure 6 and Figure 7 provide a high-level logical and physical view of cross-farm services. Figure 6
shows a logical view of cross-farm services. In this figure, you can
see an example of three farms that represent Contoso’s enterprise
services farm, Contoso’s EU farm, and Contoso’s HR farm. The enterprise
farm is currently publishing all enterprise class services that are
consumable by the organization’s other two farms. In addition, the EU
farm is consuming all the publishing services, its own services, and the
metadata service from the HR department’s farm. Finally, the HR farm is
consuming the publishing services and its own services. The key
services for these farms to consume would be the Search service and the
Secure Store service.
Figure 7 shows a physical view of another example of these same types of cross-farm services.
